Nice! I'm concerned about breaking compatibility because this is used in a few apps, do you think we could make this a backward-compatible change instead? It also looks like your spec uses URL-unsafe characters, which we could support but I think it's important to me that we could support the URL-safe base64 alphabet as well.

@christianbundy can you elaborate a bit more in what you mean about me using URL-unsafe characters? I'm url encoding them so I thought they are safe.

The safe64 function you had there IIRC replaced + signs but left / chars in it. That could pose some difficulties with standard JS routers. Thats why I url encoded the whole hash, so that all the slashes and other potentially disruptive chars were passed in a safe way. I'm mostly thinking about future clients which will probably end up using more mainstream libraries and frameworks, I think it is a good idea to url encode the hash.

What do you think?

Sorry, I mean "URI-safe" as in "you don't need to URI encode them for them to be a valid URL". I think I'd like to continue adding support for other URI formats but would prefer not to break backward-compatibility. I don't mind if we have a few different URI formats, e.g.

• %abc.sha256
• ssb:message:sha256:abc
• ssb:///mesage/sha256/abc